1. Field of the Invention
The invention is generally directed to integrated circuits, more specifically to on-chip memory provided for run-time use with on-chip logic circuits. The invention is yet more specifically directed to on-chip memory provided for run-time use within Programmable Logic Devices (PLD's), and even more specifically to a subclass of PLD's known as Field Programmable Gate Arrays (FPGA's).
2. Description of Related Art
Field-Programmable Logic Devices (FPLD's) have continuously evolved to better serve the unique needs of different end-users. From the time of introduction of simple PLD's such as the Advanced Micro Devices 22V10.TM. Programmable Array Logic device (PAL), the art has branched out in several different directions.
One evolutionary branch of FPLD's has grown along a paradigm known as Complex PLD's or CPLD's. This paradigm is characterized by devices such as the Advanced Micro Devices MACH.TM. family. Examples of CPLD circuitry are seen in U.S. Pat. Nos. 5,015,884 (issued May 14, 1991 to Om P. Agrawal et al.) and 5,151,623 (issued Sep. 29, 1992 to Om P. Agrawal et al.).
Another evolutionary chain in the art of field programmable logic has branched out along a paradigm known as Field Programmable Gate Arrays or FPGA's. Examples of such devices include the XC2000.TM. and XC3000.TM. families of FPGA devices introduced by Xilinx, Inc. of San Jose, Calif. The architectures of these devices are exemplified in U.S. Pat. Nos. 4,642,487; 4,706,216; 4,713,557; and 4,758,985; each of which is originally assigned to Xilinx, Inc.
An FPGA device can be characterized as an integrated circuit that has four major features as follows.
In addition to the above-mentioned basic components, it is sometimes desirable to include on-chip reprogrammable memory that is embedded between CLB's and available for run-time use by the CLB's and/or resources of the FPGA for temporarily holding storage data. This embedded run-time memory is to be distinguished from the configuration memory because the latter configuration memory is generally not reprogrammed while the FPGA device is operating in a run-time mode. The embedded run-time memory may be used in speed-critical paths of the implemented design to implement, for example, FIFO or LIFO elements that buffer data words on a first-in/first-out or last-in/first-out basis. Read/write speed, data validating speed, and appropriate interconnecting of such on-chip embedded memory to other resources of the FPGA can limit the ability of a given FPGA architecture to implement certain speed-critical designs.
Modern FPGA's tend to be fairly complex. They typically offer a large spectrum of user-configurable options with respect to how each of many CLB's should be configured, how each of many interconnect resources should be configured, and how each of many IOB's should be configured. Rather than determining with pencil and paper how each of the configurable resources of an FPGA device should be programmed, it is common practice to employ a computer and appropriate FPGA-configuring software to automatically generate the configuration instruction signals that will be supplied to, and that will cause an unprogrammed FPGA to implement a specific design.
FPGA-configuring software typically cycles through a series of phases, referred to commonly as `partitioning`, `placement`, and `routing`. This software is sometimes referred to as a `place and route` program. Alternate names may include, `synthesis, mapping and optimization tools`.
In the partitioning phase, an original circuit design (which is usually relatively large and complex) is divided into smaller chunks, where each chunk is made sufficiently small to be implemented by a single CLB, the single CLB being a yet-unspecified one of the many CLB's that are available in the yet-unprogrammed FPGA device. Differently designed FPGA's can have differently designed CLB's with respective logic-implementing resources. As such, the maximum size of a partitioned chunk can vary in accordance with the specific FPGA device that is designated to implement the original circuit design. The original circuit design can be specified in terms of a gate level description, or in Hardware Descriptor Language (HDL) form or in other suitable form.
After the partitioning phase is carried out, each resulting chunk is virtually positioned into a specific, chunk-implementing CLB of the designated FPGA during a subsequent placement phase.
In the ensuing routing phase, an attempt is made to algorithmically establish connections between the various chunk-implementing CLB's of the FPGA device, using the interconnect resources of the designated FPGA device. The goal is to reconstruct the original circuit design by reconnecting all the partitioned and placed chunks.
If all goes well in the partitioning, placement, and routing phases, the FPGA configuring software will find a workable `solution` comprised of a specific partitioning of the original circuit, a specific set of CLB placements and a specific set of interconnect usage decisions (routings). It can then deem its mission to be complete and it can use the placement and routing results to generate the configuring code that will be used to correspondingly configure the designated FPGA.
In various instances, however, the FPGA configuring software may find that it cannot complete its mission successfully on a first try. It may find, for example that the initially-chosen placement strategy prevents the routing phase from completing successfully. This might occur because signal routing resources have been exhausted in one or more congested parts of the designated FPGA device. Some necessary interconnections may have not been completed through those congested parts. Alternatively, all necessary interconnections may have been completed, but the FPGA configuring software may find that simulation-predicted performance of the resulting circuit (the so-configured FPGA) is below an acceptable threshold. For example, signal propagation time may be too large in a speed-critical part of the FPGA-implemented circuit. More specifically, certain synchronization signals may need to propagate from one section of the FPGA to another according to a particular sequence and architectural constraints of the FPGA device may impede this from happening in an efficient manner in so far as resource utilization is concerned.
Given this, if the initial partitioning, placement and routing phases do not provide an acceptable solution, the FPGA configuring software will try to modify its initial place and route choices so as to remedy the problem. Typically, the software will make iterative modifications to its initial choices until at least a functional place-and-route strategy is found (one where all necessary connections are completed), and more preferably until a place-and-route strategy is found that brings performance of the FPGA-implemented circuit to a near-optimum point. The latter step is at times referred to as `optimization`. Modifications attempted by the software may include re-partitionings of the original circuit design as well as repeated iterations of the place and route phases.
There are usually a very large number of possible choices in each of the partitioning, placement, and routing phases. FPGA configuring programs typically try to explore a multitude of promising avenues within a finite amount of time to see what effects each partitioning, placement, and routing move may have on the ultimate outcome. This in a way is analogous to how chess-playing machines explore ramifications of each move of each chess piece on the end-game. Even when relatively powerful, high-speed computers are used, it may take the FPGA configuring software a significant amount of time to find a workable solution. Turn around time can take more than 8 hours.
In some instances, even after having spent a large amount of time trying to find a solution for a given FPGA-implementation problem, the FPGA configuring software may fail to come up with a workable solution and the time spent becomes lost turn-around time. It may be that, because of packing inefficiencies, the user has chosen too small an FPGA device for implementing too large of an original circuit.
Another possibility is that the internal architecture of the designated FPGA device does not mesh well with the organization and/or timing requirements of the original circuit design.
Organizations of original circuit designs can include portions that may be described as `random logic` (because they have no generally repeating pattern). The organizations can additionally or alternatively include portions that may be described as `bus oriented` (because they carry out nibble-wide, byte-wide, or word-wide, parallel operations). The organizations can yet further include portions that may be described as `matrix oriented` (because they carry out matrix-like operations such as multiplying two, multidimensional vectors). These are just examples of taxonomical descriptions that may be applied to various design organizations. Another example is `control logic` which is less random than fully `random logic` but less regular than `bus oriented` designs. There may be many more taxonomical descriptions. The point being made here is that some FPGA structures may be better suited for implementing random logic while others may be better suited for implementing bus oriented designs or other kinds of designs. In cases where embedded memory is present, the architecture of the embedded memory can play an important role in determining how well a given taxonomically-distinct design is accommodated. Compatibility between the embedded memory architecture and the architecture of intertwined CLB's and interconnect can also play an important role in determining how well a given taxonomically-distinct design is accommodated.
If after a number of tries, the FPGA configuring software fails to find a workable solution, the user may choose to try again with a differently-structured FPGA device. The user may alternatively choose to spread the problem out over a larger number of FPGA devices, or even to switch to another circuit implementing strategy such as CPLD or ASIC (where the latter is an Application Specific hardwired design of an IC). Each of these options invariably consumes extra time and can incur more costs than originally planned for.
FPGA device users usually do not want to suffer through such problems. Instead, they typically want to see a fast turnaround time of no more than, say 4 hours, between the time they complete their original circuit design and the time a first-run FPGA is available to implement and physically test that design. More preferably, they would want to see a fast turnaround time of no more than, say 30 minutes, for successful completion of the FPGA configuring software when executing on a 80486-80686 PC platform (that is, a socommercially specified, IBM compatible personal computer) and implementing a 25000 gate or less, design in a target FPGA device.
FPGA users also usually want the circuit implemented by the FPGA to provide an optimal emulation of the original design in terms of function packing density, cost, speed, power usage, and so forth irrespective of whether the original design is taxonomically describable generally as `random logic`, or as `bus oriented`, `memory oriented`, or as a combination of these, or otherwise.
When multiple FPGA's are required to implement a very large original design, high function packing density and efficient use of FPGA internal resources are desired so that implementation costs can be minimized in terms of both the number of FPGA's that will have to be purchased and the amount of printed circuit board space that will be consumed.
Even when only one FPGA is needed to implement a given design, a relatively high function packing density is still desirable because it usually means that performance speed is being optimized due to reduced wire length. It also usually means that a lower cost member of a family of differently sized FPGA's can be selected or that unused resources of the one FPGA can be reserved for future expansion needs.
In summary, end users want the FPGA configuring software to complete its task quickly and to provide an efficiently-packed, high-speed compilation of the functionalities provided by an original circuit design irrespective of the taxonomic organization of the original design.
In the past, it was thought that attainment of these goals was primarily the responsibility of the computer programmers who designed the FPGA configuring software. It has been shown however, that the architecture or topology of the unprogrammed FPGA can play a significant role in determining how well and how quickly the FPGA configuring software completes the partitioning, placement, and routing tasks.
As indicated above, the architectural layout, implementation, and use of on-chip embedded memory can also play a role in how well the FPGA configuring software is able to complete the partitioning, placement and routing tasks with respect to using embedded memory; and also how well the FPGA-implemented circuit performs in terms of propagating signals into, through and out of the on-chip embedded memory.